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ABSTRACT 



One approach to designing reuseable software is to consider a program to be a 
member of a family of programs that are related through function, purpose, or lineage. 
Numerical evaluation of expressions is a function that links many programming 
environments together, such as programming languages, operations research models, and 
spreadsheet applications. In parallel, we may have type evaluation of expressions in 
these environments, a function usually performed by hand. By considering the need for 
type evaluation in these environments to constitute a problem domain from which a 
program family can be generated, a design for a type evaluator to support the family 
members is developed. Several examples of environment specific implementations are 
provided, and the degree of reuseability attained through the approach is discussed. 
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I. INTRODUCTION 



Expressions occur in programming languages, operations research models, 
spreadsheet applications, and many scientific computer based systems. Expression 
evaluation is common to all of these, and the process from recognition of an expression 
to a determination of its value is a well understood one. In parallel however, we may 
have symbolic type evaluation , which is a determination of the type of an expression, an 
attribute that occurs in a pair with its value. Built-in value evaluation of expressions is 
common to many current systems, yet type evaluation of these expressions is mostly 
performed by hand. It is usually the task of the person forming an expression to ensure 
that it is well formed in the sense of type consistency between operators and operands 
prior to using it in these systems. Many systems and applications would benefit greatly 
from the inclusion of type evaluation, leading to more powerful and secure systems. 

For example, many current operations research modeling systems are used 
infrequently and those intimate with the specifics of the system are no longer around 
when the model is used. Those who desire to use the model must leam or in some cases, 
re-leam, the details of the model in order to use it. By having a system type evaluator to 
perform data and expression validation, we can reduce the amount of time it takes to 
effectively use the system. If some part of the model is changed, for example, the typing 
of the data; a type evaluator would be able to validate the compatability of the modified 
data with the original model. Another example concerns executable modeling languages, 
which specify a type calculus for the types supported by the language. The calculus 
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suggested by Bradley and Clemence [1] supports a hierarchy of dimensional types that 
allows upward inheritance and conversion of types based on the outcome of applying 
operators in the system. By providing such a system with a type evaluator, we can check 
the composition of constraints and functions for consistency, as well as provide 
automatic type conversion. 

In many modeling systems, the model and the data are in separate files. The 
separation of model and data is natural in systems where the model is developed and 
validated, and then many different problems are formed by combining the model with 
different data files. While this design allows the inclusion of the specification of sets and 
the value of coefficients with the data, there exists the danger that a particular data file 
may not conform to the model’s type requirements [1]. By providing a type evaluator 
that is capable of performing conversions, a data file may be converted during input or 
output to conform to the specific type constraints of the model. 

A. MOTIVATION 

Pamas defines a program family as a set of programs whose common properties are 
so extensive that it is advantageous to study the commonalities between them before 
analyzing (or developing) individual members of the set [2]. From our research, type 
evaluation is a function that is common to many systems. Each of these systems has 
specific typing requirements and data structure definitions, yet the abstraction of the 
problem domain leads us to believe that type evaluation is not dependent on these issues. 
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If we say that the process of type evaluation does not change from one problem in the 
domain to another, then we may develop a family of programs with a common ancestor 
that supports the varied type and data instances. Such an approach has many benefits: 



1. Since variations in applications are to be expected, such an 
approach will minimize the amount of development needed to 
produce programs for each application. 

2. By making the process the key design problem, we may increase 
the portability of the design from one language to another 

3. Once an ancestor program is developed, it can be used in a 
library of programs, available to application designers 
whose problem specifications fall within the domain 

4. By considering all similar problems, we can better 
determine the basic design to solve the individual ones 



Since the requirement for performing type evaluation exists in many systems, we would 
like to avoid developing multiple programs to handle the various different types that 
would be found in these systems. In today’s environment of rapidly increasing software 
development costs, the approach of designing a family of programs that support many 
members from the same problem domain is of particular interest. Another critical issue 
concerns the movement within the Department of Defense to require the ADA language 
to be the primary programming language of all new systems. To fully utilize the basic 
premise of ADA, that is, modularization, we may design a program in such a way that 
many of the modules may be reuseable from one family member to another without 
modifications. 
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B. IMPLEMENTATION 



In support of this idea, a program family for type evaluation is developed and 
implemented in a Pascal-like language. The initial design discussion centers on the core 
routines of this program family which can be used by every instance of the family. The 
second part of the discussion gives several example members from the family including 
one that is used in conjunction with an executable modeling language for a transportation 
model. These examples are fully running programs that take the core routines and add 
only the type-specific routines necessary to make a complete program. 
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II. EXPRESSIONS AS A PROBLEM DOMAIN 



A. ABSTRACTION 

1. Defining the Problem Domain 

Abstraction is an intellectual tool that allows reuseability, extensibility, and 
generality to be incorporated into a design. Here we use it as a basis for program 
development. We first define the problem domain as the set of all computable 
expressions. These expressions may occur in many environments, such as mathematics, 
programming languages (e.g. PASCAL, FORTRAN, ADA ), in operations research 
modeling systems, spreadsheets, etc. We can then further identify the problem domain as 
those environments which contain expressions and require the evaluation of them. By 
examining representative members of this set of problems, we observe that they may be 
viewed in abstraction to have certain common features. These are: 

- there are processable elements of the domain 

- there are process operations in the domain 

- there exist relationships among the processable elements 
and the operations 

- there are precedence relationships amongst the operations 

Next, we analyze these features to determine which are the non- changing base objects of 
any expression. We call every processable element an operand and every process 
operation an operator. For the purpose of our discussion we restrict ourselves to unary 
and binary operators, as virtually all systems support these. 
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An operator in a language can be characterized informally as a token which 
specifies an operation of function evaluation. An operand is a token which specifies a 
value, either literally (as a constant) or indirectly (as an identifier). An expression is then 
a sequence of operands, operators, and grouping indicators ( delimiters, such as 
parathesises) [3]. 

2. Language of Expressions 

Every expression in the problem domain is composed of operands and operators. 
Since these operators and operands can be composed together to create expressions, we 
must have rules to do so. Typical rules as presented in Aho & Ullman [4] are: 

1. A single operand is an expression. 

2. If @ is a binary infix operator and El and E2 are 
expressions, then El @ E2 is an expression. 

3. If @ is a unary prefix operator and E is an 
expression, then @E is an expression. 

These rules then define the relationship among operators and operands. When we 
combine operators to form expressions, the order in which the operators are to be applied 
may not be obvious. For example, a + b + c can be interpreted left to right (left- 
associative) or from right to left (right-associative) [4], We may also force the 
associativity of an expression through the use of parathesises, as is done in most 
programming languages. We' can then add another rule, 

4. If E is an expression, (E) is an expression. 

Another relationship among operators is the notion of precedence. For example, the 

expression a + b * c can be grouped according to a chosen associativity rule, however the 
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associativities of + and * do not tell us which is preferred. We therefore use precedence 
rules to determine the proper grouping of operands and operators [4], We then let these 
elements be the basis for all generalized expressions, and consider the rules for 
expression construction a formal grammar for a language. 

B. TYPING IN EXPRESSIONS 
1. Meaning of Type 

The value evaluation of expressions is a well known subject, but our interest is 
in symbolic type evaluation of these expressions. We must answer, what is the meaning 
of the type of an expression, and what is involved in the process of type evaluation? 

With each expression is associated a value , which is determined by the values 
of its operands, the functions satisfied by the operators, and the sequence in which the 
latter are applied to the values of their arguments [3]. If we consider instead of values of 
operands the types of the operands, then we may define the type of an expression to be 
the result of applying type sensitive operators to the operands of the expression. That is, 
when type evaluation is performed, the type of each operand is substituted for its 
symbolic name in applying operators, and then the expression is evaluated according to 
the semantics of the operators [5]. For example, in most programming languages, all 
operands have a type attribute, be it the usual well known ones of real, integer, boolean, 
character (base types), or some complex type, such as arrays or records whose fields are 
base types. These type attibutes of the language objects are then used in syntactic and 
semantic processing of language statements, including expression evaluation. 
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2. The Process of Type Evaluation 



During compile time checking of an expression such as 
a ( of type integer ) + b ( of type real ) 

operand "a" is implicitly converted to a real type, and then during run-time the "+" 
operator is applied. What is in effect occuring during the compile time check is type 
evaluation , and this is the process we wish to identify. 

To begin with, we note that the simple example expression is composed of two 
operands and a binary operator. During syntactic validation of any statement in any 
language, the completeness of the statement is checked, and we assume in this case that 
the binary operator has associated with it two operands and it is formed in the correct 
infix order. The next step is two-fold: 

(1) Determine whether each operand is type correct for the 
operator 

(2) Or, if not, whether the operand can be converted to a type 
consistent with that operator. 

In step (1), various mechanisms are used in compilers to perform this function, for 
example, look-up tables that use the operator and the operands as entries into a matrix of 
allowed combinations, and returns a true-false answer. Since step (2) is really part of the 
answer to step (1), we can include an identification of which operand(s), if any, can or 
need to be converted as a part of the answer returned from the look-up table. Then, if a 
conversion is required , we can insert a new operator into the expression, a "convert from 
old type to new type" operator that acts as a unary operator during run-time evaluation. 
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In Figure 2- 1 we view the expression as a binary tree before and after the conversion is 
added. These inserted type conversions can then be used to bubble-up the result type of 
the tree during type evaluation of more complicated expressions, as they inherit the type 
resulting from the symbolic application of the conversions to their children. During 
value evaluation, the inserted conversions are applied to their children and the resultant 
value is passed up the tree. 

In the abstract, type evaluation consists of recursively (1) traversing through an 
expression until an operator is encountered, (2) locating the associated operand(s) of that 
operator, (3) symbolically evaluating this sub-expression through some mechanism that 
returns a type and identifies required run-time conversions (or detects type consistency 
errors) and (4) inserting these conversions in the proper location within the expression. 
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Figure 2-1. Type conversion inserted into tree 
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ID. PROGRAM DESIGN 



A. DESIGNING FOR CHANGE 

1. Design Principles 

Because we have chosen the program family approach to the design, we are 
planning for inevitable changes from one instance of the program to another. We use 
information hiding and modularization as the basic principles of our design to help plan 
for change. By isolating the changeable parts into modules and defining module 
interfaces that are insensitive to change, the problems associated with transforming a 
program from one application to another can be minimized [6]. That is, by encapsulating 
secrets into modules, restricting the information distribution between modules, and 
viewing the program as a set of modules that have well defined interfaces, we design in 
flexibility that is not found in other designs (like, for example, designs that are composed 
of a chain of data transforming components). The other critical principle we follow is to 
put off the design of the data structures as long as possible. In this way we remain as 
close as possible to the abstraction of the problem during design, and can better capture 
the key algorithms of the process without needless detail. 

2. Identifying the Changes 

Most programs undergo changes during their life cycle, whether these are 
modifications during the design phase, post-implementation upgrades, or extensions to 
original capabilities. By deciding to use the program family approach, we desire to 
design flexibility into our design in the sense of allowing ease of modification and 
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extension from one application to another. 

Those modifications and extensions we are primarily concerned with are the 
different data structures which support type information from one application to another, 
the different actions of the operators that perform evaluation of these different type data 
structures, and the environment in which the expressions may be found. Another view of 
the problem may focus on the environment in which these expressions are being 
evaluated in. Clearly, the evaluation process does not change with the environment, but 
the types and the operators do. That is, the environment in which an expression occurs 
changes. If we are assuming that the environment will change from one application to 
another, we want to encapsulate that change through modularization [7]. For example, 
one application may use the simple arithmetic operators to evaluate an expression of 
types real and integer. For an application that must perform type evaluation of matrices 
whose entries are also reals and integers, we have a set of operators for matrix 
arithmetic. Another application may combine sets of record types, with the fields of the 
records composed of boolean, numerical, and string types, with set operators. Type 
evaluation in this environment may involve a determination of equality of members of 
the sets, in which case the types of each member must be compared. So the environment 
will change from one application to another as the language or system in which the 
expressions are composed changes. In one instance the expressions may be the right 
hand side of an assignment operator, as is found in most programming languages. 
Another may represent the validation of the result type of a function in a modeling 
language. In any case, the environment must be constructed in which the type evaluation 
of the expression is valid. This means defining the allowed operators, constants, variable 
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declarations, parameters, functions, and initializing them as necessary. We need a core 
program that can easily be modified to different environments. 

B. PROGRAM DESIGN 

1. Creating the Environment Through Declarations 

In any environment, we say that an object has a value and it has a type. Type 
evaluation of an expression involves getting the types of the objects in the expression, 
which means the object must be known to the environment. This presents several issues: 

(1) How does the environment know about the objects? 

(2) When are the objects assigned type? 

For (1), we say this action occurs during the declaration phase, in which statements 
indicating what kind of object is declared are made to the system in the language of the 
environment. For example, in Pascal, there are constant, type, and variable declaration 
blocks in which a user may enter the information to identify objects of these kinds. In a 
spreadsheet, a user fills in blocks or whole lines and columns with names and values or 
predefined system functions such as sum, division, and total (for a column of figures). 
Modeling languages also use statements for declaring objects to the system, such as 
functions, constraints, or parameters. Since this declaration phase is common to all these 
systems, we want to include this capability in our program family. As for (2), type 
assignment may be static, with the type declared during object declaration, or it may be 
dynamic in the sense that a declared object may be assigned the type resulting from the 
type evaluation of an expression. For example, in spreadsheet applications, a block may 
be identified to be the sum of an entire column of figures. The type may then be 
determined during evaluation of the sum operation and assigned to that block. In 
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languages, the modeler may declare what the type of a function should be, and then use 
the resultant type from the evaluation of the function to validate the declared type. We 
may also encounter mixed systems, in which the typing of the data is mixed with the 
model. For some objects in the model the type may be part of the data and thus only 
available at run-time. We consider only static typing, in the sense that the type of all 
objects is assigned prior to run-time and these type assignments are not changed dynami- 
cally during execution, since this is the common capability in most languages. From 
these basic requirements, a user model is defined that satisfies them, as depicted in Figure 
3-1. It takes an input source that defines the environment through declarations, performs 
environment declared functions on objects in the environment, and returns the results. 
For our research, we are concerned with expression evaluation as an environment func- 
tion. Since the validity of the expression depends on the language of the environment , 
we first focus on the change in language from one environment to another. 



Declare 




Use objects declared 


Env i ro nmen t 




in environment 


(Objects & 


aaai^^* 


defined functions 


Functions) 








Figure 3- 1 . User Model 



a. Interpreting the Language 

A valid expression is composed of declared objects , but these objects must 
be identified in and extracted from some source language. If we consider the 
environment to be defined through a language, then the declarations phase can be thought 
of as an interpretation of the source language. In compilers this interpretation is done via 
a sequence of steps: 

a. lexical analysis 

b. syntactic analysis 

c. semantic analysis/processing 

d. storage allocation 

e. target code generation 

f. assembly 

We borrow the first three steps, replacing the last three with operations and functions 
necessary to achieve the desired results. The lexical and syntactic analysis will constitute 
the recognition phase, while the semantic analysis will be type evaluation. Whereas a 
compiler produces intermediate code that reflects the types of operations available in a 
specific machine [3], our semantic process reflects the mechanisms available for type 
operations in a specific application and produces the type resulting from the symbolic 
evaluation of an expression. 

b. Lexical Analysis 

The primary task of lexical analysis is to assemble characters from the input 
stream into tokens, and to determine which terminal symbol of the language each token 
is an instance of [3]. The terminals are classified for this purpose into lexical token types. 
Since our approach is to build a program family, and the language (environment) of the 
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expressions from one family member to another may change, we build a generic lexical 
analyzer module, which may be accessed by application specific syntactic analyzers. It is 
generic in the sense that it always return a scan token from the same set of possible 
'generic" scan tokens, regardless of the environment. The set of possible generic scan 
tokens may be defined over a domain of input that is common to all applications, and 
these become the building blocks of application specific tokens. Since the lexical 
analyzer will not change, it becomes one of the program family core elements. 

As most languages consider identifiers to begin with an alphabetic 
character, and real and integer numbers to be recognizable objects, we will include these 
as generic token types. Lanugages differ in interpetation of the various other printable 
and non- printable (control) characters, so these will be considered as special tokens, 
with the exception of "end of line" and "end of file". These are used as indicators in most 
languages so it seems natural to identify them as separate objects. We can then define 
the ASCII character set to be the domain of our generic scanner function, and the range 
to be as follows: 

(1) An identifier token begins with a character in [A..Z,a..z] 
ends when the next character is non- alphanumeric 

(2) An integer consists of a string of numerals and ends 
when the next character is non-numeric 

(3) A real consists of a string of numerals, a decimal, 
followed by one or more numeric characters and ends 
when the next character is non-numeric 

(4) Blanks 

(5) The "end of line" token 



20 



(6) The "end of file" token 



(7) All other ASCII characters are special tokens 

For consistency, we also include an "unknown" token for error handling. 

A scanner may need to look ahead in the input stream while building tokens 
(for example, to determine when it has seen the last character of a token), so we use a 
buffer to hold the contents of the input. The buffer itself can also remain unchanged 
from one family member to another and we need to have certain buffer functions to 
access it without errors and support the lexical analysis. The following are then provided 
as elements of the buffer module: 

procedure Fill(Buffer): 

Prepares input to be accessed via buffer operations 

function Empty(Buffer): 

Returns status of buffer 

function LookAhead: 

Returns next character without consuming it 

function GetChar: 

Returns next character and consumes it 



Any environment specific syntactic analysis that requires a token must go through the 
generic lexical analyzer, and we define the interface to be: 

procedure GetScanToken: 

Builds one of the generic tokens by using buffer operations 



By using a generic lexical scanner, we lose some of the processing power of a fully 
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specific one, so we shift some of the work to the application specific syntatic analyzer. 
For example, the scanner may return the character which is a special token as 
identified by the generic lexical analyzer, followed by an identifier as two separate 
tokens. If the environment recognizes identifiers that begin with to be declared a 
certain type of identifier, then the specific syntactic analyzer would combine the two into 
one token prior to using it. 

c. Syntactic Analysis 

While every environment may have differences in typing information 
representation, operator naming, and the expected order in which environmental 
information is encountered in the input stream, we assume that in all of the environments 
one or more of the following occur: 

- objects such as constants, variables, types, and parameters 
are declared in the environment prior to use 

- the types of the objects can be assigned during the declaration 
phase 

- or, the type of an object may be assigned by evaluating an 
expression 

- or, the type may be assigned after evaluating an expression 
and then comparing that type to the expected type 

During syntactic processing we need to determine which kind of declaration 
is to be made according to the stream of tokens. This is performed by recognizing 
sentences in the language of the environment. In compilers, this language recognition 
occurs through a syntactic analyzer that operates based on a fixed language. Since we 
expect the language to change and we already have a generic lexical analyzer to get the 
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tokens for use in this recognition process, we may look at which functions are common 
to all sentence recognitions. We can make these functions individual, generic pieces of 
the program family syntactic analyzer. Then, we can tailor make an environment specific 
analyzer through the ordering and repetitive use of these functions to recognize the 
language. 

First we note that in any sentence a language recognizer may do several 
things upon encountering a token from the lexical analyzer: 

- it may recognize it as valid and consume it, possibly causing 
an action to occur 

- it may use it to construct an environment specific token, 
which also consumes it 

- it may ignore it and look for the next token 

- it may have expected a different token, causing either a 
warning or error to be produced 

From one language to another we want a function that can do these actions based on 
requests from the current state of syntactic analysis. We define the function 

GetNextScanObject(Reql,Req2,Req3,Req4,Req5,Req6,Req7,Req8) 

that based on a request being either Yes (for get the object). No (for ignoring the object), 
Warn (for generating a warning), and Err (for generating an error and halting the scan 
process), can be used to return any of the following eight generic tokens: 



23 



1. Identifiers 

2. Real Numbers 

3. Integers 

4. Special Characters 

5. Blanks 

6. End of Line 

7. End of File 

8. Unknowns 



For example, a call such as 

GetNextScanObject(Yes,Yes,Yes,Wam,No,No,Err,Err) 

would return the next identifier, real number, or integer returned by the lexical analyzer, 
ignoring all blanks and end-of-lines. Warnings would be issued if any special characters 
were encountered during the process, while the end-of-file or unknown token would 
cause an error message and system halt. Another common feature in sentence recognition 
is that the validity of the current token in the sentence depends on what the next token is. 
The function LookAheadNexScanObject returns the next token without consuming any 
tokens. This token can then be compared to what the recognizer expects, and that result 
used to control the recognition process. 

Since we have said that the generic token types include those kinds of 
tokens recognized by most environments such as identifiers, real numbers, and integers, 
but also a group called special tokens which will be viewed differently in the various 
environments, we need a common way to detect whether the current special token is one 
expected, or to use it in syntactic control. We use the function 
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IsSpecialToken(Current_Token,Expected_Token) 



that takes as its arguments the current token and the environment expected token, 
returning a boolean response to the comparison. All of these functions then become core 
elements for the program family syntactic analysis phase, and it depends on the 
environment as to how and in what order they are used. 

The next step in the recognition phase is to determine what action takes 
place after a sentence is recognized. Since the recognition of a valid sentence must result 
in a declaration, this action must install the objects in the environment for possible later 
access. If we consider the varied environments, it could be a variable or parameter being 
declared, it could be a function declaration, or any object in the environment. For each 
of these, the recognition must result in the object being stored through some semantic 
action. Our semantic action will cause the object to be stored in a symbol table. 
Initially, we will have the name of the object, but each object has other attributes as well. 
The attributes of each object include: 

- its name 

- its type 

- its value (numerical, boolean, other ) 

- the kind of object it is (eg operator, operand) 



The type assignment of each object will occur at some point in the process, so this is a 
common function. Since each environment will use different types and different data 
structures to capture the type information for inclusion into the symbol table, we need a 
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procedure that reflects this common function in all the environments but hides the 
specific typing details. We then define the function name and interface to be function 
GetTypelnfo that will syntactically analyze the typing information. It will return the 
kind of object recognized, its value, create the data structure for the types allowed in the 
environment, and return this information. Since the typing information will vary from 
environment to environment, we return only a pointer to the typing data structure. The 
object and its attributes must be put into the symbol table so we provide the function 
Insert which creates a symbol table entry and installs the object into the table. The table 
must also be initialized, which includes creating it and filling it with environment specific 
operators. The procedure Initialize(Symbol_Table) is defined by name and argument, 
but will be specific to each environment. At this point we can identify the lexical and 
syntactic analyzer modules, as well as the symbol table module in Figure 3-2. 

2. Type Evaluation Phase 

a. A Generalized Expression Grammar 

Having considered that the environment of the expressions changes, we also 
want to incorporate flexibility in terms of changing types in our design of the type 
evaluator. By viewing it from a user’s point of view, we can determine what it is that is 
changeable from one user (environment) to another. We say a user has one or more 
expressions and wants a program that evaluates them and returns their types, or detects 
errors. Expression (operand) types and operators may include: 

- unary or binary 

- arithmetic 

- boolean 

- matrix/vector 

- interval arithmetic 
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Buffer 



Generic Lexical Analyzer 
Ge tScanToken 



Fill (Buffer ) 
Emp ty(Buffer) 
Loo kAhea d 
Ge tCha r 



Symbol Table 

Initialize + 
Insert 



Syntactic Analyzer 



Ge tNex tScanObj ec t 
LookAheadNextScanObj ect 
I sSpe c i a IToken 
GetTypeInfo + 



+ - Indicates routines modified for specific application 



Figure 3-2. Elements of the Program Family 



- dimensional units 

- others as defined by the user during declarations 
Errors detected include: 



- incorrect operand type matched with an operator that 
does not operate on that type 

- missing operand(s) 

- missing operator 

- incompatability between the types in two sub-expressions 
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We expect the types and operators will change, but not the error handling requirements. 
To detect errors, compilers use parsers to recognize a valid sentence in a grammar. If we 
call expressions the sentences of our language, then we need a grammar that recognizes 
them. 

We have said that the process of type evaluation will not change from one 
environment to another, yet the operators may. We need to hide this change in our 
grammar. From our abstraction, the operators have precedence and degree. We may 
define a grammar that captures the precedence and degree of operators, but in a way that 
preserves information hiding. If we assume that all the operators in the problem domain 
are either degree 1 or degree 2 (that is, unary or binary), and that they can be placed in a 
finite set of precedence levels, we can define a grammar for expressions in general. For 
instance, unary -, unary +, "NOT", "sum", "sin", and "log" are all unary operators and can 
be placed in a class we term UOP. The usual arithmetic operators "+" and are placed 
in the class BOP1, as well as the boolean operator "OR". Multiplication and division are 
in BOP2, since their precedence is lower then addition and subtraction, along with 
"AND", since its precedence is lower than "OR". The relational operators "=", ’<’, ’>’ 
and so on are in the class EQOP, which have the lowest precedence. By lowest 
precedence we mean they are applied after all other operators. For example, our 
precedence classes could be: 

UOP : NOT, unary -,+, Sqrt, Sin, etc 
BOP1 : *,/, Mod, And 
BOP2 : +,-, OR 
EQOP : =,<,>,<=,>= 
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We then provide one production rule for each level of precedence and terminal and write 
the grammar as: 

Exp — > Term (EQOP Term)* 

Term — > Factor (BOP2 Factor)* 

Factor — > Primary (BOP1 Primary)* 

Primary — > Element I UOP Element 
Element — > Operand I (Exp) 

This becomes a generalized grammar for recognizing an expression [4], 

Grammars of this form that are left-factored and have no left-recursion are 
suitable for use in a top-down parsing technique, so we use recursive descent. Each 
production in the grammar is transformed into a recursive procedure, and by including 
semantic actions at appropriate places in the code we transform the expression from an 
infix list to a postfix tree, suitable for use by the type evaluator. To include more levels 
of precedence we would define each level as a new production in the grammar and then 
write it as a recursive procedure. We call this the expression parser, and it will be 
another core routine of the program family. 

b. Symbolic Type Evaluation and Conversion 

Now that we have the expression represented as a binary tree with the root 
node and all internal nodes as operators and all the leaves as operands, we want to 
symbolically evaluate it. This is the same as getting the type of the root node, which 
depends on the types of all its children. Not only do we want to get this type, but we 
want to insert any allowed type conversions into the tree in the proper position so that 
during actual value evaluation they will be handled in the correct sequence. We can then 
say that to perform type evaluation/conversion, we need three things: an algorithm for 
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traversing the tree, a mechanism for determining the types of the inner nodes depending 
on the operator at those nodes, and an algorithm for inserting conversions. 

We implement the traversal algorithm as a function that returns the type of 
the root node of the postfix tree. In order to get the type of the root node, it must 
recursively descend the tree, get the types of all sub-expressions, and bubble up the 
result. If the expression is simply an operand, the root node has no children and its type 
is obtained from the symbol table. If the expression is a unary operator and an operand, 
the root is the unary operator and it will inherit the type of its child. Similarly, if the 
expression is more complex, the algorithm must determine the types of its right and left 
children, then, depending on the kind of operator that is the root node, the type of the root 
node is determined by symbolically evaluating this sub-expression. That is, there will be 
different mechanisms for determining the type of the root and all inner nodes depending 
on whether the operator is multiplicative, additive, boolean, or other, and on the types of 
the children (operands). But these mechanisms do not affect the traversal algorithm, as it 
is only concerned with whether the root node is an operand, a unary, or a binary operator. 
To implement this traversal algorithm, we use a recursive procedure GetType with the 
following design features: 
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- the argument to GetType is a pointer to an object 
in the tree, which is in the symbol table 

(since all operands and operators are in the table) 

- this argument is checked against a case statement 
to determine how to continue traversing the tree 
and when to call the look-up mechanism, based 
on the kind of object as: 

Case object of: 

operand : get the type from the symbol table 
unary op : 1 . get the type of the right child 
using GetType 
2. call look-up function to 
symbolically evaluate operator 
binary op: 1. GetType of right child 

2. GetType of left child 

3. call look-up function to 
perform symbolic evaluation 

- If it’s an undefined type, meaning it is not found in 
the symbol table, a nil pointer is returned 



Since the algorithm does not depend on what specific kind of operation is involved, for 
instance ,+ or *, rather on whether it is an operand, unary operator, or binary operator, 
the algorithm will remain unchanged from environment to environment. 

During this traversal, calls are being made to a look-up function in order to 
symbolically evaluate sub-expressions. What changes during these calls are the symbolic 
evaluation mechanisms in function LookUp, as these have knowledge of the 
environment specific types and operators. The functions that these mechanisms perfom 
will be the same: 

(1) determine if the operator and operand(s) are consistent 

(2) return the result from symbolically evaluating the 
operator and operands 

(3) identifies which, if any, of the operands 
require conversion 
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One method of look-up mechanism is to use tables, with one table for each operator and 
the types as indices into the table. Rather than determine all possible operator and type 
combinations , which would result in large and complicated tables of different sizes, we 
use instead routines that explicitly check for type validity, identify the conversions 
required, and return the result of the type evaluation based on the operator. Because a 
member program will be designed for a particular environment, the allowable type 
conversions will be known and can be written into these routines. By specifying only the 
interface to these routines, we preserve infomation hiding and allow the internals of the 
routines to be designed as the user desires. In the function LookUp , we include a case 
statement such that for the recognized operator, the environment specific evaluation 
routine (mechanism) is called. As an example, we need a different evaluation routine for 
the types real & integer, string, and array for the additive operator "+". 

As the traversal algorithm in GetType is indepedent of the specific operator 
types, so is the insertion algorithm in function LookUp. We implement this indepedent 
process as procedure Insert_Conversion , that takes as its’ arguments the left and right 
operands and the identified conversion operator and inserts it in the correct branch of the 
tree. 

We can now identify the type evaluation module and identify those parts 
that are considered core routines for the program family and those that are environment 
specific in Figure 3-3. 
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